場景：週一早會，昨晚剛發版。另一個還在開發的「報表匯出」昨天差點被合進 main。

小可：「昨天發版終於順利了，但是誰把半熟的『報表匯出』提前往 main 推？我半夜心臟差點又熄火。」

貝老闆：「我以為 main 就是最新最好，先合起來不香嗎？」

小可：「main 是可上線穩定版本，不是最新。最新在 feature/*，你要先在 feature branch 確定功能都 ok 才能進 main！你把半熟的菜端上桌，客人肚子會說話。」

貝老闆：「那 Release Branch 到底解決什麼？」

小可：「好威說的你到底有沒有在聽，兩個目的：凍結跟可追溯。切了 release/2025.08.0 後，只收修補（bugfix），不再加新菜。發完打 v2025.08.0，出了問題能回到那一包。」

（免提電話打開）

好威：「分支策略像捷運：feature/* 是支線先繞一圈；release/* 是發車月台，不再臨停載客；tag 是班次編號，出事時能精準回到那班車。昨晚你們運氣好，是 CI 把半熟菜擋下來。」

貝老闆：「懂了。那我昨天想加的 PDF 匯出為什麼不能跟車？」

小可：「缺權限矩陣與壓測報告。Release 只收修補，你那是新功能…還是沒測完的…」

好威：「補兩件事：1）release/* 設受保護分支，強制 PR＋綠燈 CI；2）DB migration 要有 down，沒有回梯誰都不敢住。」

貝老闆：「行。我去跟客戶說：這班車不加掛，下一班準點。」

踩坑瞬間

• 把 main 當「最新分支」，導致半熟功能混入可上線版本。
• 發版前臨時「靈感」加料，Release Branch 被解凍，風險激增。
• Migration 只有 up 沒有 down，回滾像沒有電梯的高樓。

好威解析 - Release Branch 的工作

目的：隔離風險、縮短復原時間；把「要上線的集合」凍結在一個可追溯的分支，通常越難發布的情境越需要，比如說要跟硬體整合的 app。

• 切版：release/年.月.序號，封版後只收修補。
• 打標籤：正式上線以 tag vYYYY.MM.X 標記，產物可回滾。
• 回灌：Release 上的修補要合回 main（或 develop），避免「修過卻下個月再壞一次」。

精煉重點：Release Branch 讓上線靠紀律，不靠運氣。

概念拆解 (更細節可以用這些詞問 AI)

1. 三種常見策略：

• Git Flow：feature → develop → release／hotfix → main。適合多人、明確發版節奏。
• Trunk‑Based：短命分支從 main 切、快速合回，強依賴 CI/CD 與 feature flag。
• Release Train：固定班次發車，不為功能等待，降低協調成本。

2. Release 的邊界管理：

凍結後禁止新功能；若真的卡案子，只能 cherry‑pick 「必要修補」，並準備回滾與驗收清單。

3. 可回滾才叫安全：

• 版本化產物（容器映像、壓縮包），標註 git sha 與 tag。
• DB migration 有 down，或採「向前相容」策略。

4. 分支保護與 CI/CD：

• main、release/* 強制 PR、至少 1–2 位 Reviewer (或叫 AI 再 Review 一次)、必須綠燈測試。
• push → release/：自動佈署到 Staging；tag → v：產生 Release Notes、部署 Production。

實作小抄（僅收最小命令)

# 切版與凍結
git switch -c release/2025.08.0 main

# 只收修補：必要時挑單筆修補
git cherry-pick <commit_sha>

# 發版打標籤
git tag -a v2025.08.0 -m "August 2025 release"
git push --tags

# 回灌修補避免下次再踩
git switch main
git merge --no-ff release/2025.08.0

Vibe Programming × AI 協作

• Changelog 生成：丟 git log --since="2025-08-01"＋ conventional commits，請 AI 產生語義化版本與 Release Notes 草稿。
• 上線檢核表：讓 AI 讀 Dockerfile、K8s 清單、migrations 清單，生成健康檢查、警示閾值、回滾步驟。
• PR 初審：AI 先檢視安全風險、測試缺漏、相依變更提示，人再二次審。

範例 Prompt：

「根據以下 commit 與變更檔，建議版本號、草擬 Release Notes，列出風險與回滾方案。若含 DB
Migration，請提供 down 設計與資料備援策略。」

Takeaways - 帶走這三點

1）Release Branch 是事故保險槓：把「可上線集合」封裝在可追溯的分支，封版只收修補，任何臨時靈感都等下一班車，避免把風險帶上客戶桌面。

2）流程比工具重要：受保護分支、PR 審查、CI 綠燈、語義化版本與回灌紀律是最小土木工程。沒有這些，再多工具也只是更快把錯佈署出去。

3）用 AI 把繁瑣變自動：讓 AI 產出 Changelog、檢核表、風險清單與回滾步驟，人類負責判斷與最後拍板，能讓發車準點又可回頭。

今日提問

你們現在走 Git Flow、Trunk‑Based，還是沒有固定策略？最常在哪個環節出事：凍結太晚、回灌遺漏，還是沒有回滾？為什麼？

小作業（可丟給 AI）：

「請依我專案目前的 commit 與部署方式，產出 release/2025.08.x 的上線檢核表、回滾指南，以及
GitHub Actions 的分支保護與發版工作流程 YAML。」